home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Nov 90 / MacApp.Tech$ 11⁄2⁄90 / 2266-Re[2] Auto-Initializ-Oct90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.7 KB  |  62 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  PERRY.G      to PHIL.TH
  2.  
  3. Item    3697528                         29-Oct-90        07:29PST
  4.  
  5. From:   V0683                           Amoco Tech, Eric Berdahl,VAR
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.         GER.XSE0067                     Germany - Norbert Lindenberg,IDV
  9.  
  10. Sub:    Re[2]: Auto-Initialized Objec
  11.  
  12. Norbert,
  13.  
  14. My argument against doing Failable things in Initialize methods (read:
  15. constructors) is two-fold, as you indicated.
  16.  
  17. In the C++ world, constructors are wonderfull things.  They can ensure that
  18. anytime after saying new TFoo, your instantiated object is internally
  19. self-consistent.  This means that its pointers and references are real and that
  20. everything has a default value.  However, the invocation of the constructor
  21. makes the lines of exception handling a little fuzzy, so we say "Don't do
  22. things in the constructor that can fail."  One of these no-nos is necessarily
  23. memory allocation.
  24.  
  25. Given the fact that the Initialize method is now the formalized constructor for
  26. MacApp objects, we can apply the same arugment to Robert's improvement to the
  27. MacApp MakeNewInstance routine.  "But wait!" you say, "MacApp also provides a
  28. nice failure handling mechanism, so why can't I do failable things?"  This is
  29. an excellent question because it gets to the root of the objective idea of
  30. constructors (read: Initialize method).  Constructors (read: Initialize
  31. methods) construct.  Initializers (read: IFoo methods) initialize.
  32. Constructors are sort of no-brainers for the idea of initialization.  They put
  33. everything into "known, safe states."  Eiffel has one such mechanism built into
  34. its whole being.  Eiffel sets integers to 0, booleans to false, and object
  35. references to void.  C++, because of such things as const and reference data
  36. members must have some formalized constructor to deal with these concepts, so
  37. it foists the initialization to the programmer.  Pascal does nothing.  MacApp
  38. leaves it to the first part of the IFoo method.  Thus, IFoo can be thought of
  39. as the following:
  40.  
  41. pascal void TFoo::IFoo()
  42. {
  43.     //  construct my Foo object with code here
  44.     this->IFoosParentClass();
  45.     WithFreeUponFailureDo { //  WithFreeUponFailureDo courtesy of CPlusMacApp.h
  46.         //  initialize my Foo object with code here
  47.     }
  48. }
  49.  
  50. Objectively, this is messy because it combines the two concepts of construction
  51. and initialization into one method.  A better object abstraction would be to
  52. separate these ideas into two separate methods.  Thus, we come back to the
  53. concept that constructors construct and initializers initialize.  Construction
  54. simply puts things into "safe, known states" and thus does not involve
  55. allocations or other failable things.
  56.  
  57. Waxing eloquent (kind of),
  58. Eric Berdahl
  59. Amoco Technology Company
  60. AppleLink:  V0683
  61.  
  62.